home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19941221-19950208
/
000180_news@columbia.edu_Mon Jan 16 16:46:18 1995.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
10KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA03580
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Mon, 16 Jan 1995 11:46:24 -0500
Received: by apakabar.cc.columbia.edu id AA25613
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 16 Jan 1995 11:46:22 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Kermit File Transfer and tn3270
Date: 16 Jan 1995 16:46:18 GMT
Organization: Columbia University
Lines: 169
Message-Id: <3fe7sq$p0a@apakabar.cc.columbia.edu>
References: <173276AEB.BDESIMON@uga.cc.uga.edu>
Nntp-Posting-Host: watsun.cc.columbia.edu
Keywords: Mainframe, 3270
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <173276AEB.BDESIMON@uga.cc.uga.edu>,
Bert DeSimone <BDESIMON@UGA.CC.UGA.EDU> wrote:
>Gotta figure this has come up before. We are evaluating a terminal server
>that supports tn3270. No problem using MS-Kermit to connect to the terminal
>server and connect via tn3270 to an IBM mainframe. However, file
>transfers (either invoking server on the mainframe or not) always fail.
>Connecting through this same terminal server to the same mainframe
>through a 7171 presents *no* problem with file transfer. (BTW: I don't
>have to be using tn3270 on a terminal server; file transfers with Kermit
>using tn3270 on a Unix host fail the same way).
>
>I am speculating that the mainframe Kermit must send a transparent mode
>sequence, ordinarily processed by the protocol converter, that is causing
>the problem.
>
One of the major strengths of the Kermit protocol is its ability to
transfer files with IBM mainframes over a wide variety of connection
types, and there is an excellent Kermit software program for the IBM
mainframe, which is available for VM/CMS, MVS/TSO (and ROSCOE), CICS, and
MUSIC. The current version is 4.3.0, with version 4.3.1 in beta test.
All of the Kermit books and manuals ("Kermit, A File Transfer Protocol",
"Using MS-DOS Kermit", "Using C-Kermit", and the IBM mainframe Kermit
online manuals) describe the process(es) in some detail. Here is a brief
summary.
Half-duplex (local-echo), line-at-a-time connections are generally handled
by the "ibm" macro that is built in to MS-DOS Kermit and C-Kermit, which
performs the following protocol-related settings:
set local-echo on
set parity mark
set flow none
set handshake xon
Full-screen sessions go through a 3270 terminal emulator. This can reside
anywhere between the client software (such as MS-DOS Kermit) and the
mainframe. For the past 10 or 20 years, the most common place to find the
3270 emulator was on a special purpose "protocol converter": a box that
has serial lines on one side and a connection to the mainframe on the
other. This box generally works by tricking the mainframe into thinking
it is a "control unit" with multiple 3270 terminals attached, and at the
same time tricking the terminals into thinking they are communicating with
a "normal" ASCII character-at-a-time host. The box converts between 3270
data streams and ASCII terminal (e.g. VT100) conventions. This includes
ASCII/EBCDIC character-set conversion, cursor positioning and screen
painting, and keystroke interpretation.
As you can imagine, all of these conversions would normally have a
disastrous effect on Kermit protocol packets, and also upon any other type
of data that has to be transmitted "as is", without conversion, such as
graphics terminal directives. Thus, many protocol converters support a
"transparent mode", that allows the mainframe host to command them to turn
off their conversion functions, and at a later time, turn them back on.
When everything works as planned, the only Kermit commands required for
going through the protocol converter are:
set flow xon/xoff ; (usually)
set parity even ; (or other)
Everything else corresponds to the normal Kermit defaults (remote echo,
no "handshake", etc).
Unfortunately, the method for entering and leaving transparent mode
differs from one 3270 emulation product to another. Ideally, there are
two components: (1) the identification phase, in which the mainframe
software issues a special instruction that causes the protcol converter to
respond in a unique (but harmless) way; and (2) the actual enter- and
exit-transparent-mode directives.
IBM Mainframe Kermit needs to know which kind of transparency, if any, is
used by the protocol converter so it can be put into transparent mode at
the beginning of packet protocol and taken out of it upon return to
interactive command mode. There are several ways that mainframe Kermit
can go about this. First, you can use the SET CONTROLLER command to tell
it which style of transparency is used by the protocol converter. Second,
mainframe Kermit can be set up by the system administrator to always use a
particular style. Third, it can attempt to "autodiscover" the controller
type by issuing various types of identification queries and checking the
results. The third method is not very reliable, however, since many types
of protocol converters fail to respond to these queries even when they do
implement a particular style of transparency.
Nowadays, special-purpose protocol converters are giving way to general
purpose terminal and compute servers that include a "tn3270" function.
tn3270 is a special kind of TELNET program that also performs 3270
emulation, and requires that the mainframe be on TCP/IP network and have
a TN3270 server. Here are two examples:
1. UNIX tn3270. Most UNIX systems come with a tn3270 program that lets
you make a full-screen connection to an IBM mainframe. Once you have
made the connection, you should be able to start Kermit on the
mainframe, give it a SEND, RECEIVE, or SERVER command, escape back to
your terminal emulator (e.g. MS-DOS Kermit), and transfer files
without any special settings. If you have trouble with this, then:
. Ask mainframe Kermit to "show controller". If it doesn't say
Series/1, then tell it to "set controller series1".
. Try using shorter packets. The maximum length that can pass
through the protocol converter might be less than what you are
trying to use. A typical maximum value might be 1700.
. Tell one or both Kermit programs to "set parity space".
2. Cisco terminal server tn3270. Current releases of Cisco terminal
server software include a tn3270 feature that is supposed to permit
Kermit transfers, but it has bugs. Sometimes these bugs can be worked
around by using the methods listed in (1) above and specifying VERY
short packets, like 30 or 40 bytes. Sometimes they can't be worked
around at all. A future release of Cisco software (probably 10.3)
will include new tn3270 software that implements Series/1-style
transparency correctly, and allows Kermit transfers of both text and
binary files in both directions using packet lengths up to about 1900
(or whatever the total screen size is).
If you try all of these workarounds with your terminal server and still
get failed transfers, make packet logs and/or debug logs in both Kermit
programs to find out what the terminal server is delivering to each Kermit
program, and report the misbehavior to your terminal server vendor.
For further information about specific protocol converters and how to
configure IBM Mainframe Kermit for them, please read the ik0aaa.hlp file
that comes with IBM Mainframe Kermit.
Finally, it is possible to transfer files through a 3270 fullscreen
connection even when 3270 emulator can't be put into transparent mode at
all. You can read about this in the C-Kermit update notes file
(ckcker.upd) and the MS-DOS Kermit update notes files (KERMIT.UPD).
Quoting from the latter:
"Doomsday Kermit" (DDK) techniques allow file transfer with IBM mainframes
through 3270 protocol converters that do NOT support transparent mode, to be
used in conjunction with IBM Mainframe Kermit's SET CONTROLLER FULLSCREEN
command on VM/CMS, MVS/TSO, or CICS. MS-DOS Kermit 3.13 or later and IBM
Mainframe Kermit 4.2.3 or later required. Commands:
SET PARITY EVEN ; Or whatever
SET FLOW XON/XOFF ; Or whatever
SET SEND START 62 ; Greater-than sign
SET RECEIVE START 62 ; Ditto
SET BLOCK BLANK-FREE-2 ; New block-check type
SET HANDSHAKE NONE
BLANK-FREE-2 is a new block-check type, exactly like type 2, except encoded
to never contains blanks. Give IBM Mainframe Kermit the following commands:
SET CONTROLLER FULL
SET SEND START 62
SET RECEIVE START 62
SET BLOCK BLANK-FREE-2
SET HANDSHAKE 0
Doomsday Kermit file transfers are not as reliable as regular Kermit protocol
transfers, and they are much slower. Use this method only as a last resort;
that is, only when you can't get a transparent-mode fullscreen connection or
a linemode connection to the mainframe.
(end quote)
And beyond finally: in the future, we expect to add 3270 emulation to the
Kermit software itself, so you will be able to make tn3270 connections
directly from Kermit to the mainframe without having to go through a
"black box" for the conversion. Of course, Kermit software will handle
transparency correctly (and automatically). (And no, I can't estimate
when built-in 3270 emulation will be available.)
- Frank